<!DOCTYPE html>
<html lang="en">

<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Closing a GCC Release Branch</title>
<link rel="stylesheet" type="text/css" href="https://gcc.gnu.org/gcc.css" />
</head>

<body>

<p>This page documents the procedure for closing an old release branch.</p>

<ol>

<li>Inform the gcc@gcc.gnu.org list that the branch is being
closed.</li>

<li>On master, edit <code>active_refs</code>
in <code>contrib/gcc-changelog/git_update_version.py</code> to stop nightly
version updates from touching the branch.  Remove the entry
in <code>maintainer-scripts/crontab</code> that creates snapshots from
the branch.  Optionally, remove any code
in <code>maintainer-scripts/gcc_release</code> that is only relevant
to snapshots from that branch or older branches (for example, if
directories listed in the script were removed or renamed after that
branch).  Check in and push those changes.  Run <code>git pull</code> in
the <code>gcc-checkout</code> directory of the gccadmin account, and then
actually install the updated crontab there.  Edit
<code>hooks-bin/commit_checker</code> in gccadmin home directory,
increment number on line above
<code>error(f&#39;Release branch gcc-{branch} is closed.&#39;)</code> and
commit the changes.</li>

<li><p>For every open bug whose summary contains the version number of
the branch being closed and an indication that the bug is either
specific to that version, or a regression in that version and possibly
later versions (for example, "[7/8 Regression]"), read the
comments on that bug and determine what versions the bug is present in
and what versions it is fixed in.  (Some bugs whose summary contains
the version number may in fact be saying "GCC 7 has bug X" or
similar when reporting a bug present in earlier and later versions as
well; nothing need be done with such bugs after identifying that they
are of that form.) Several things should be done for all regression
and version-specific bugs for the branch being closed:</p>

<ol>

<li>Ensure that the version number of the branch at the time it is
closed (for example, "7.5.0" if the branch is being closed when that
is the version number a compiler built from the branch would report)
is listed in "Known to work" or "Known to fail" as applicable.</li>

<li>If the bug is a regression that is not fixed on all subsequent
release branches and on trunk then it needs to remain open.  Remove
the version number of the branch being closed from the summary (for
example, change "[7/8 Regression]" to "[8 Regression]".  If the
milestone is not set, or is set to a version from the branch being
closed, set it to the version number of the next release from the next
oldest release branch.

The step can be done by <code>maintainer-scripts/branch_changer.py</code> script
with the following arguments:<br/>
<code>./branch_changer.py api_key --new-target-milestone=8.5:9.4 --remove 8
--comment 'GCC 8 branch is being closed.'</code>
<br/>
The script invocation changes target milestone from 8.5 to 9.4 and removes
'/8' from a '[Regression x/y/z]' summary line.  Moreover, a new comment is added.

Unless you add <strong>--doit</strong>, the script runs in dry mode only.
</li>

<li>If the bug is not a regression and is fixed on trunk, or if it is
a regression but is fixed on all subsequent release branches and on
trunk, it should be marked FIXED.  "Known to work" and "Known to fail"
should be updated to indicate the passing and failing versions on
subsequent release branches.  The target milestone should be set to
the earliest version in which the bug was fixed within the first
release branch on which it was fixed.

Re-run the same script command from the previous step in order to get list
of all PRs that can be closed.  This script will list them now.
</li>

</ol></li>

<li>There may also be open bugs with a milestone set to a version from
the branch being closed but without the regression marker in their
summaries.  Search for such bugs with any milestone from the branch
being closed.  Handle them as described above, generally removing the
milestone if they remain open and are not regressions.</li>

<li>Adjust the order in which milestones appear on the bug search form
so the milestones for the closed branch no longer appear at the top.
Edit products, select gcc, and edit the target milestones.  Change the
Sortkey for each milestone from the closed branch with a value of 0 to
have Sortkey 100 instead.</li>

<li>Edit the bug searches on the main <code>index.html</code> web page
so they no longer include the milestones from the closed branch.
Remove any entry describing the state of the closed branch from that
page.</li>

</ol>

</body>
</html>
